Encrypted Connections

When using Vitalware over public networks it may be desirable to encrypt all data transferred between the Vitalware client and server. Vitalware 2.2.01 has been extended to support an encrypted connection between the client and server programs. The encrypted connection uses TLS v1.0 (Transport Layer Security) for the transmission of data, ensuring data integrity and security. The use of data encryption is optional and is not required for internal networks where the risk of unauthorized access to data is minimal. The Vitalware server may also be configured to accept connections only from clients who request data encryption. This provides System Administrators with the ability to enforce data encryption, or not, as required.

Support for encrypted connections between the Vitalware client and server requires the following software versions:

  • Texpress 8.2.009 or later
  • Vitalware 2.2.01 or later
  • TexAPI 6.0.02 or later
  • TexJDBC 0.9.6 or later

If any software is earlier than the version listed above, Vitalware will drop back to using unencrypted connections. In order to use encrypted connections the System Administrator must create the required keys (public / private) and public digital certificate and install them on the Vitalware server. The CA certificates may also need to be installed on the Vitalware client.

The TLS v1.0 protocol uses Public Key Infrastructure (PKI). A key is a sequence of bytes, normally 40, 56, 64, 128 or 265 bits in length, which is used by a cipher (an encryption algorithm) to encrypt data. Using the same cipher with different keys will produce different output. Hence, the key is used to "lock" the encrypted data. In order to unlock the data, that is decrypt it, the right key is required. With public/private key infrastructure two keys are generated, a public key and a private key. Data encrypted with the public key requires the private key in order to be decrypted and data encrypted with the private key requires the public key in order to be decrypted. In other words the keys are symmetrical.

The private key must be kept safe to ensure data privacy. If someone has both the private and public keys, they can decrypt the data and so compromize data security. The public key may be made available to anyone without compromising security as the private key is required to decrypt data encrypted using the public key. The public key is wrapped in a digital certificate, which consists of:

  • Public Key
  • Subject - details about the owner of the certificate.
  • Serial Number - unique number used to identify the certificate.
  • Issuer - details about who verified and issued the certificate.
  • Valid Dates - start and end dates for which the certificate is valid.
  • Key Usage - purpose(s) for which the public key may be used.
  • Thumbprint - a check-sum to ensure the certificate has not been modified.

In order for a digital certificate to be valid it is necessary to verify the details of the Issuer. A small number of companies are allowed to issue valid and verifiable certificates. When you want a public digital certificate you approach one of these companies and they verify your details before issuing your public digital certificate. They sign your certificate with their own private key, making them the Issuer. In order to read your digital certificate you need the Issuer's public key. The key is embedded in their digital certificate which is available freely. These Issuer public digital certificates are known as Certificate Authorities (CA). In order to verify your certificate it is necessary to determine who the Issuer is and locate their CA certificate. Using the public key in their certificate your certificate can now be decrypted and the check-sum verified to ensure it has not been altered.

The private key is stored on the Vitalware server. Login access to the Vitalware server is generally restricted to user vw, hence the key is not available for general access. The public digital certificate is also stored on the Vitalware server. All CA certificates are stored with the Vitalware client.

When a connection is initiated the Vitalware server sends its public digital certificate to the Vitalware client. The client uses the CA certificates stored locally to verify that the certificate is valid. The server's public digital certificate contains the full host name of the Vitalware server machine. The Vitalware client checks the host name against the machine to ensure it has not connected to a rogue server.

Once the Vitalware client has verified the server's public digital certificate it sends a random number to the server encrypted using the public key in the server's digital certificate. As the server is the only machine with the private key it can decrypt the random number. The number is used as a key to a cipher (an encryption algorithm). The cipher uses the key to encrypt all data between the client and server. As the client and server are the only two machines which know the encryption key, data security and integrity is guaranteed.

The complete steps required to establish an encrypted connection are:

  • The Vitalware client connects to the Vitalware server requesting a secure connection. The client provides a list of ciphers it supports.
  • The Vitalware server selects the strongest cipher it supports from the client's list and notifies the client.
  • The Vitalware server sends its public digital certificate to the client. The certificate contains the server's host name, the Issuer used to create the certificate and the server's public encryption key.
  • The Vitalware client looks up the CAs on its machine and verifies that the server's certificate is valid.
  • The Vitalware client generates a random number and encrypts it with the server's public encryption key. The random number is sent to the server.
  • The Vitalware server decrypts the random number using its private encryption key (known only by the server).
  • The random number is used as a key for the selected cipher. All data transferred is now encrypted using the agreed cipher.

Vitalware allows public digital certificates to be:

  • Self signed

    A certificate that is verified by itself, that is the Issuer certificate is the same as the certificate itself. Self signed certificates allow institutions to generate their own digital certificates without the need to have them authenticated by an outside authority. In order for the certificate to be verified the self signed certificate must exist on both the client and server machines, the client version being the CA certificate.

  • Root signed

    A certificate verified by one of a select set of "root" certificates. A root certificate is distributed as part of the public key infrastructure and can be installed on client machines to provide certificate verification.

  • Chain signed

    A certificate is verified by its Issuer certificate. The issuer certificate itself is verified by its issuer certificate and so on until either a root or self signed certificate is found.

Vitalware allows both the client and server machines to define a list of ciphers they will support. When a connection is created the strongest (that is hardest to break) cipher supported by both the client and server is selected. System administrators may restrict the ciphers available on the server, forcing the client to use very strong encryption only (e.g. 256 bit ciphers).